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REMARKS 

Tlie Applicants have reviewed and considered the current Office Action and any 
reference(s) cited therein. Claim 29 is herein amended; no claims are herein canceled; 
and no claims are herein added. As a result, Claims 1-16 and 18-31 are pending in this 
application. Claim 29 has been herein amended to correct a grammatical error. 
Specifically, the word "and" has been added between the third and fourth element of the 
claim. 

The Applicants thank the Examiner for the courtesy of a telephone interview on 
March 18, 2008. During the telephone interview, the Examiner explained that the 
Response filed on December 1 1 , 2007 (the "Response") was sufficiently responsive to 
the rejection in the Office Action of September 1 1 , 2007 as the Response applied to 
Claims 1 -1 6 and 1 8-28. However, the Examiner explained that the Response was not 
fully-responsive in that the Response did not present discussion or argument of how the 
newly added Claims 29-31 were patentable over the cited art. The Applicants contend 
that Claims 29-31 are patentable over U.S. Patent Publication No. 2003/0233420 issued 
to Stark et al. ("Stark") in view of U.S. Patent No. 6,507,866 issued to Barchi ("Barchi") 
for at least the same reasons that Claims 1-16 and Claims 18-28 are patentable over 
the combination of Stark and Barchi. 

The present claims require, among other limitations, detecting an outbound 
message from an originator computer system and verifying an authenticity of an 
originator identity associated with the outbound messages. Thus, enforcement 
mechanisms of the present invention are applied to originator identities, not originator 
addresses or fields in a message header (as is done in Barchi). The originator identity, 
as explained in the specification, identifies the sender of messages from information 
obtained when the sender opens a connection from an originator computer system. 
The originator identity may be an account name, for example. The originator identity is 
not the same as the originator address because a new IP address may be assigned to 
the originator computer system each time the originator identity opens a connection. 
Additionally, the originator identity is not necessarily found in a field in a message 
header. In fact, the present invention addresses the situation when a field (e.g., the 
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FROM field of a message header) is changed by a sender after a connection is opened. 
Accordingly, the present invention can apply the same message count and message 
limit when applying the enforcement mechanism against messages having different 
addresses (i.e., because the messages came through two different connections by the 
same originator identity) or against messages having different information in the FROM 
fields of the messages (i.e., because the originator identity changed the information in 
the FROM field of one or more messages). 

Stark does not address the problem of spamming at all. If anything. Stark 
teaches away from the present invention because Stark provides a sender of a 
message to have more control over how the message is processed. See, for example. 
Paragraph 14. The text cited by the Examiner in at least one previous Office Action 
(i.e.. Paragraph 48) indicates that an address may be authenticated with an SMTP 
email account, for example. However, Stark does not teach or suggest an enforcement 
mechanism for spamming because Stark does not teach or suggest the spamming 
problem at all. The present invention, on the other hand, uses an enforcement 
mechanism involving message counts and message limits to restrict senders so as to 
reduce the amount of spam that can be sent from a sender's originator identity. 

Barchi teaches an enforcement mechanism, but Barchi does not teach or 
suggest a mechanism for applying the enforcement mechanism to the originator 
identity. That is, Barchi does not address the problem of spoofing at all and does not 
teach or suggest that any solution to spoofing is needed. Instead, Barchi teaches away 
by teaching the reader to do exactly what should not be done to avoid spoofing. That is, 
Barchi, in text cited by the Examiner (i.e.. Column 8, lines 1-8), teaches that a message 
header field contains information identifying the originator of a received email. Thus, 
Barchi teaches a reliance on field information that the originator may have intentionally 
falsified. 

Additionally, Stark and Barchi are not even properly combinable. First, Barchi 
teaches away from the present invention. Barchi teaches identifying "undesired e-mail 
messages by receiving e-mail messages, storing fields including at least one field from 
the header of each received e-mail message and analyzing the stored fields for a least 
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one pattern indicative of undesired e-mail messages." Barchi at col. 4, lines 58-67. 
Barchi teaches that received emails contain headers that are created when "a sender- 
SMTP establishes a two-way transmission channel with a receiver-SMTP." Id. at col. 1, 
line 26 to col. 2, line 23. Barchi teaches methods that extract information from headers 
in incoming e-mail messages (i.e., received e-mail messages). See, for e.g.. Id. at col. 
6, line 7-8 ("For example, fields from the 821 header and/or the 822 header may be 
extracted in the Hunt Mode."). Accordingly, Barchi teaches operating on received e- 
mails only after a two-way transmission channel with a receiver-SMTP is established 
and the headers having the extractable information are created. 

The present invention, on the other hand, operates on outbound messages. The 
present invention, as a whole, has the benefit of not having to open up two-way 
transmissions to those recipients that exceed a message limit associated with the 
originator identity. Transmission only occurs to those recipients that do not exceed the 
message limit. 

Second, changing Barchi to operate on the sending side would destroy some of 
the purpose and functionality of Barchi. Barchi teaches protecting "the receiving e-mail 
system not only against malicious users, but also against such events as routing 
accidents." Id. at col. 5, line 64 to col. 6, line 3. Barchi can only protect against routing 
accidents if the mechanism is employed at the receiving end, after emails have been 
routed (i.e., transmitted). The present invention, although providing benefits absent in 
Barchi, does not provide protection against routing accidents. This is because the 
present invention operates at the sending end, before emails are transmitted or routed. 
The present invention can reduce the number of emails routed by checking message 
limits associated with an originator identity and only routing those messages that are 
under the limit. However, once an email is transmitted in accordance with the present 
invention, any routing accidents can only be dealt with at the receiving end. 

Attempting to operate the methods in Barchi at the sending end would eliminate 
the ability of Barchi to protect against routing accidents, effectively destroying at least 
some of the purpose of Barchi. One of ordinary skill in the art at the time of the present 



U.S. Application No.: 09/715,641 Attorney Docl<et No.: ZIPOO-01 

-20- 



invention would have no motivation to combine Barchi with any art (e.g., Stark) if the 
resulting combination would destroy some or all of the benefits of Barchi. 

Barchi also teaches detecting large numbers of e-mail messages sent to a single 
recipient. Id. at col. 7, lines 14-16 ("For example, for a list maintained for purposes of 
identifying undesired use in the form of many originators sending e-mail messages to a 
single recipient."). See also. Id. FIG. 6 and accompanying text ("The logic shown in 
FIG. 6 checks for whether the number of e-mail messages to a single recipient has 
exceeded predetermined threshold."). If Barchi is to be capable of counting all 
originators sending e-mail to a particular recipient, then Barchi must be operating at the 
recipient. If Barchi were moved to the sending side, then Barchi would only see 
messages intended to be sent to the particular recipient that originated at the sending- 
side server. Since it is well known in the art that there exist many sending-side email 
servers, Barchi, operating on a sending-side server, would only see a small fraction of 
the e-mails sent to the particular recipient, again defeating one of the purposes of 
Barchi. 
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Conclusion 

Applicants contend that it would not have been obvious to one of ordinary skill in 
the art at the time of the present invention to combine Barchi with Stark as suggested by 
the Examiner. Moreover, the combination of Stark and Barchi, even if properly 
combinable does not render the present claims obvious. The Applicants respectfully 
submit that the claims are in condition for allowance and notification to that effect is 
earnestly requested. If the Examiner believes that a telephone conversation with the 
Applicants' representative would facilitate prosecution of this application in any way, the 
Examiner is cordially invited to telephone the undersigned at (508) 616-9660. 

Respectfully submitted. 
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